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The Mail Must Go Through... 


A look at the BBS message forwarding network 
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here are now close to forty full- 
service packet bulletin board sys- 
tems in Northern California, a similar 
number in the southern part of the state, 
and thousands more across the country 


and around the world. You can enter a 
message on any one of these BBSs and, 
if it’s addressed correctly, have it 
delivered to any of the other systems 
worldwide. Here in Northern California, 
more than a thousand personal messages, 
bulletins and NTS messages are entered 
into the packet network every day. More 
than two-thirds of this traffic is of a per- 
sonal nature, messages going from one 
ham to another. Bulletins account for 
about a quarter of the messages, with the 
remaining five to ten percent being made 
up of messages from the National Traffic 
System. 


Have you ever wondered how all of 
these messages get delivered? How does 
a message entered in California get sent 
to a BBS in New York? What deter- 
mines the routing that’s used for delivery 
of a message from San Francisco to a 
BBS in Los Angeles? How do bulletins 
get distributed? This article will answer 
those questions and a lot more as we give 
you an in-depth look into the BBS for- 
warding network. 


The BBS Forwarding Network 


When I first got on the air with packet 
in 1985, there were only about a dozen 
BBSs in the state. I can remember 
W6CUS, N6IIU, AA4RE and 
WAO6NWE as being the first BBSs in this 
area. Messages were sent from one BBS 
to the other on the same frequencies used 
by the users, in most cases on 2 meters, 
often going through several digipeaters 
along the way. Twenty five messages in 
one day was about the average back then. 
As more and more hams got involved 
with packet radio and the number of 


BBSs increased to accommodate them, 
the amount of traffic quickly increased. 
There soon was a need for a separate 
network to tie all of the BBSs together 
and to free up the user frequencies. 


The Northern California bulletin 
board system operators (Ssysops) met on 
a quarterly basis to discuss mutual inter- 
ests, system developments, problems, 
and so on. In the fall of 1986 the group 
was authorized the use of 223.58 Mhz as 
a “BBS forwarding frequency” and by 
the end of the year most of the systems 
had established a second port on that 
frequency. This greatly reduced the con- 
gestion, traffic moved more quickly be- 
tween systems, and all seemed to be in 
fine shape. This situation didn’t last for 
long, though. Soon 223.58 was con- 
gested and there was a need for more 
frequencies. NETROM was then avail- 
able, so nodes were installed to help 
move traffic easier, but there was still the 
need for more spectrum. 


Working with the Northern Amateur 
Relay Council of California (NARCC), 
the repeater coordinating group, packet 
users were authorized five more frequen- 
cies in the 220 MHz band, and that was 
the beginning of today’s packet network. 
The present scheme for organizing the 
BBSs into a network was developed: 
Northern California was divided into 
several smaller areas with the BBSs in 
each of these areas able to send traffic to 
one another on a single frequency. Each 
of these groups was called a Local Area 
Network (LAN). Each BBS could pass 
messages outside of its LAN by using the 
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Editorial 


Mike Chepponis K3MC 
Welcome again, folks! 


All of us on the staff of the Downlink hope you all ap- 
preciated our efforts for the Spring 1990 edition. We had fun 
putting it together, and hope that you had fun reading! Maybe 
even some of the information was useful? We trust that this 
Summer 1990 edition will suit your fancy, too! 


For this issue, we continue with our tradition of high-quality 
journalism. We’ve got our usual excellent article by Larry 
WB9LOZ, a super article by Weo Moerner, WN6I, on Emer- 
gency BBS for EOCs, an overview article by Fred Moore, 
KG6HQ, about his high tech global walk, a Dayton report by 
one our very own members of the BoD of NCPA, and a whole 
lot more! 


This is all very surprising and refreshing! So much is 
happening compared with other parts of the world in packet 
operation here! We are fortunate to have such a large talent 
pool of people here in Northern California who are willing to 
share pieces of their experience with us. 


What is perhaps even more amazing is that this newsletter 
was assembled in record time! You see, our Board of Directors 
said that we should produce the Summer issue of the Download 
at warp speed to get the quarterly back on a reasonable schedule. 
So, those of us on the editorial staff really had to scramble to 
get this one together! Sometimes, tight deadlines bring out the 
best in people! 


If you are new to NCPA and perhaps are seeing our newslet- 
ter for the first time, won’t you consider joining us? There is a 
membership application stapled to the middle of this newsletter, 
and yearly dues are only $10. When you join NCPA, you will 
receive all of the newsletters we have published so far that 
membership year, and you’ll become a member of the largest, 
growing organization of digital users in Northern California! 
Your participation in NCPA ensures a vital future for packet in 
our area! 


Our newsletter schedule is quarterly, once per season. We 
intend to stuff your mailbox with a fresh copy of the Downlink 
on or about January Ist, April 1st, July 1st, and October Ist. 
The deadlines for article submission are one month before the 
delivery dates, above. Since we are a quarterly, what we 
publish will tend to be high-quality, first run material that is not 
of a “bulletin” nature. Everything will have some connection 
to packet or to other digitial modes or things concerning digital 
communications. 


But you be the judge! Please, we appreciate your feedback! 
And, we appreciate your articles even more! Any comments of 
any kind that you might have on this newsletter can be directed 
at me via the BBS network to K3MC @ 
K3MC.#NOCAL.CA.USA.NA - and this is a pretty painless 
way to contact me and to get your ideas known! It is also the 
best way to submit your article for consideration for publica- 
tion. 


And, lastly, this issue marks the halfway point for your 
editor. Yes, I volunteered to do this because I believe that a 
vibrant newsletter is required for a vibrant NCPA! With only 
two issues left to my commitment, I am eagerly seeking others 
who want to “learn the ropes” and have some fun making the 
NCPA Downlink happen! 


Vy 73! -Mike Chepponis, K3MC 
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220 “backbone frequency,” one that tied 
all of the LANs together via adjacent 
nodes; this network was called the Wide 
Area Network (WAN). Although there 
have been several changes and refine- 
ments over the past few years, this net- 
work is the one still in use today. 


We now have six LANS: Sacramento 
Valley (SACVAL) which covers the area 
from Dixon and Sacramento north to 
Redding, East Bay (EBAY) covering 
Contra Costa County, the Sierras and the 
central valley, North Bay (NBAY) for 
BBSs in San Francisco, Richmond and 
Berkeley south to Fremontand Palo Alto, 
South Bay (SBAY) serving the Silicon 
Valley area, Monterey Bay (MRYBAY) 
for the systems on the south and west side 
of the Santa Cruz Mountains, and one 
that has never had a name and has always 
been called “the other LAN,” centered 
south and east of San Jose. 


When the network was first estab- 
lished, all of the systems in the network 
would send messages to each other. If 
the AA4RE BBS in Gilroy had a message 
for someone at the WD6CMU BBS in 
Richmond, it would connect direct to 
WD6CMU via the 220 backbone fre- 
quency and send it. At the same time, if 
the K6RAU BBS in Merced had a mes- 
sage for a user of the W6PW BBS in San 
Francisco, it would connect direct and 
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send it. As the volume of traffic in- 
creased, the number of BBSs using the 
backbone frequency at the same time in- 
creased and we once again faced a great 
deal of congestion. 


To limit the number of BBSs using the 
backbone, the “Gateway” concept was 
put into use. Each LAN now has a 
“Gateway BBS.” The six gateway BBSs 
are: SACVAL-WA6RDH, EBAY- 
KA6FUB, NBAY-W6PW, SBAY- 
W8GEC, MRYBAY- N6IYA, and 
“OTHER”-AA4RE. Messages for other 
LANs or for BBSs outside of California 
are sent first to the LAN gateway BBS. 
The gateway then uses the backbone to 
send the messages to the other gateways 
which will then send them to appropriate 
system within their LAN. Let’s look at 
some specific examples. First, let’s say 
a user of the W6FGC BBS in Twain 
Harte enters a message for a user of the 
N6QMY BBS in Fremont. W6FGC 
would send the message to KA6FUB, the 
EBAY LAN gateway, KA6FUB then 
sends it to W6PW, the NBAY LAN 
gateway, and W6PW would send the 
message to N6QMY. Now another ex- 
ample: A KB6IRS user in Soquel enters 
a message for someone who uses 
WAONWE in Sacramento. KB6IRS 
would send the message to N6IYA, the 
MRYBAY gateway, then N6IYA would 
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send it to WA6RDH, the SACVAL 
gateway, which would send it to 
WAO6NWE. With only 6 LAN gateways 
using the backbone frequency, the con- 
gestion is limited, allowing traffic to 
move more quickly from LAN to LAN. 


Getting Your Message to the 
Right Place 


As I mentioned at the beginning of 
this article, a message can be entered on 
any BBS for any other full-service BBS 
in the world. (Personal BBSs and TNC 
mailboxes are excluded.) You can enter 
a message for someone who uses a BBS 
in New York just about as easily as you 
enter a message for someone who uses 
the same BBS as you do. You have to 
make sure that you address the message 
correctly, though, indicating the callsign 
of the other BBS and the two letter state 
abbreviation. Let’s say we want to send 
a personal message to Bob, NG2P, who 
uses the WB2WXQ BBS in Rochester, 
New York. At the prompt we would 
enter: SP NG2P @ WB2WXQ.NY 
separating the BBS call and the state 
abbreviation with a period. It’s as simple 
as that! 


NTS messages use a special address- 
ing format: ST zipcode @ NTSxx where 
the xx is the state abbreviation. An ex- 
ample would be ST 61644 @ NTSIL for 
a message going to Peoria, Illinois. Note 
the use of ST for NTS messages, rather 
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than SP, which is used for personal mes- 
sages, or SB, which is used for bulletins. 


How does your BBS know how or 
where to send that message to NG2P or 
that NTS message to Peoria? Each BBS 
has a forward file that’s used for this 
purpose. The forward file contains in- 
dividual sections for each station the 
BBS connects to, indicating the connect- 
ing path, the times to connect, and the 
callsigns or designators of the messages 
to be sent. This file is set up by the sysop 
for his particular BBS, and he has to 
make sure that the listing is correct or 
messages will be sent to the wrong BBS. 


Since I’m the sysop of W6PW, I'll use 
the W6PW forward file as an example 
here. I have a section for each BBS in the 
NBAY LAN and asection for each of the 
other five gateway BBSs. Most of the 
sections are short, containing only the 
call of the BBS, appropriate zip codes for 
forwarding NTS messages and possibly 
a few special designators. A few of the 
sections are quite lengthy, however. 
W6PW forwards most messages leaving 
California to N61YA, since he has a port 
on the 20 meter HF net. The N6IYA 
section in the W6PW forward file con- 
tains the BBS calls of all MRYBAY sys- 
tems, every appropriate state 
abbreviation, all non-California NTS 
designators, and the country and con- 
tinent codes used for sending messages 
outside of the US. 


In the past, the forward file contained 
all of the BBS callsigns in the US, but it 
got to the point where it was impossible 
to keep the list up to date, so the use of 
the state and country abbreviations was 
introduced. Now the forward file has 
only the callsigns of California BBSs, 
state and country abbreviations and NTS 
and bulletin designators. The message to 
NG2P would be sent to N6IYA based on 
the “NY” in the address, not the BBS call. 
When it arrived in New York, the BBS 
call would then be used for the remainder 
of its trip. The NTS message for Peoria, 
Illinois, would be forwarded using the 
“NTSIL” address. 


The KA6FUB and AA4RE sections 
of the W6PW forward file contain the 
callsigns of all the Southern California 
BBSs, since messages for the southern 


part of the state are handled by either one 
of those gateways. KA6FUB uses a 
route down the central valley, while 
AAA4RE uses a coastal route. Messages 
for Southern California from NBAY 
LAN users might be sent via either route; 
which one depends solely on which BBS 
W6PW happens to connect to first. 


Each BBS begins a forwarding cycle 
once every hour. It first does a com- 
parison of all messages on the system 
with the calls, abbreviations and desig- 
nators in the forward file. When it finds 
a match, it uses the information given in 
the file to connect to the appropriate sta- 
tion and then sends the message. All 
messages for a particular BBS are for- 
warded before it moves on to the next 
BBS. In addition, before disconnecting, 
there is a check to see if there are any 
messages to be sent back to the BBS 
originating the connection. This is called 
reverse forwarding. 


Bulletin Distribution 


Finally, we need to look at how bul- 
letins are sent to everyone. There are 
several designators used for bulletin dis- 
tribution: ALLCAN - Send to all BBSs 
in Northern California, ALLCAS - Send 
to all BBSs in Southern California, 
ALLCA - Send to all BBSs in the entire 
state of California, ALLUSW - Send to 
all BBSs in the western United States, 
USA - Send to all BBSs in the country, 
plus special local designators. For each 
designator, there is an associated dis- 
tribution list of BBS callsigns. When a 
message is received with one of these 
designators on it, a special line is added 
to the message listing showing the calls 
from the distribution list. That line is 
then scanned for comparison to the for- 
ward file during the forwarding period. 
As before, when a match is found, the 
bulletin is forwarded. This method al- 
lows the same message to be sent to many 
different stations automatically. 


To prevent duplication of bulletins, 
each one is assigned a unique bulletin 
identification (BID) when it’s first 
entered. When a bulletin is to be for- 
warded, the receiving BBS is first sent 
the message’s BID. The BBS checks to 
see whether or not it has the message and 
then returns either “OK” (send it, I don’t 


have it) or “NO” (I have it already). This 
method of distribution prevents break- 
downs in the forwarding chain if one or 
more of the BBSs are off-line. Here in 
Northern California each of the LAN 
gateways forwards bulletins to the other 
gateways and each BBS within a LAN 
forwards bulletins to all others in the 
LAN, so there is plenty of duplication. 


Many bulletins, such as those from the 
ARRL or AMSAT, are assigned a BID 
by the originating agency. By assigning 
these bulletins a unique BID, only one 
copy is received by each BBS, even 
though the bulletin may have been 
copied from computer phone networks or 
RTTY broadcasts, etc., and entered into 
the packet network at several points. 
Normally generated automatically by the 
BBS at which the bulletin is originated, 
the BID in these cases can be entered 
with a variation of the send command, as 
in: SB ARRL @ ARL $ARLB0512 


Messages going to other states, except 
for the states right near the California 
boarder, are sent to the BBSs with HF 
ports. We have seven HF stations at the 
present time: 40 meters: W6CUS; 30 
meters: N6EEG; 20 meters: N6IYA - 
beamed east, N6OMPW - beamed toward 
the Pacific Net, and KB6GOZ; 15 
meters: N6OA; 10 meters: WW6L. Each 
gateway sysop has to determine which 
HF station to use for the messages leav- 
ing his LAN. Depending on the state or 
country of destination, the time of the 
year and band conditions, the choice of 
HF station can vary quite frequently. 
The HF sysops will often advise the rest 
of us as to what areas they are able to 
work to help us in making the correct 
decision. 


There have been continual changes to 
the network as it’s expanded to meet the 
needs of the day, and there have been 
changes in the methods used for forward- 
ing the traffic. The use of packet con- 
tinues to grow, so we can expect further 
changes in the months ahead. Rather 
than more frequencies, more BBSs and 
more nodes, the future changes will be 
based on new transmission methods, in- 
creased data speeds, compressed mes- 
sages, and other means of increasing the 
quantity of data being sent from one sys- 
tem to another. Watch for an- 
nouncements of these changes in the 
months ahead. 


EOT 
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Dayton 1990, or, Here We Go Again. 


Mike Bothe, KB6OWT 
Linda Rae Sande, N6QYU 


f I could use only one word to 

describe the 1990 Dayton Ham- 
Vention it would have to be “stale”. 
While attendance was about the same as 
last year and the usual exhibitors were 
present, nothing struck me as being really 
exciting. 


The impression that I got from some 
of the other exhibitors was even one of 
“ho hum”. Heathkit was at the Dallas 
HamCon last year with a booth that took 
a day to setup and was very impressive, 
but at Dayton with only a few simple 
tables. 


I had hoped to see ICOM’s new 
receivers, the R 1 and R 100, but was told 
that production problems would delay 
release for some time. 


AEA had a new HF antenna, the Iso 
Loop, that is a boon to those of us that 
need to operate a clandestine HF station 
from our condo’s or other areas with 
restrictive zoning laws. 


In talking with several other Amateurs 
afterwards, I got the same impression - 


DXPSN Corner 


Tom Wood N6IXX 


i, my name is Tom Wood, 

N6IXX. I’m_ the “Network 
Coordinator” for the DX Packet Spotting 
Network. I operate a DXPSN node on 
145.770 in Walnut Creek. 


This is the first in what I hope will be 
several articles concerning the DXPSN, 
and what is going on there. This article 
will be of a general nature, with sub- 
sequent articles covering specific ac- 
tivities on the DXPSN. 


The DXPSN is a multiuser system. 
We recently set a new user record of 145 
connects at the same time. These con- 
nects were spread over the 12 existing 
nodes state wide. 


If you have not checked into the 
DXPSN, we invite you to do so. You 
might not be a “DX type,” but I think you 
will find the technology interesting none- 
theless. While we are still working on 
implementing a method for external mail 


“where was that one thing that you just 
couldn’t leave without?”... it just wasn’t 
there. (Those who were on the lookout 
for commercial pagers or radios had 
much better luck than us Amateurs in this 
respect.) 


One thing I did notice was that one or 
two of the junque dealers that normally 
reside in the flea market area migrated 
inside to the main show floor. These are 
the purveyors of the dreaded dancing 
flower, the golf umbrella, and other such 
junque that doesn’t belong at a ham 
show! 


As usual, DARA did a super job of 
staging the HamVention. There were 
ample things for non-ham spouses to do 
while the other half drooled over the 
acres of superlative values in the flea 
market. Also, buses were used to 
transport the throngs of attendees from 
hotels to the Hara Arena and back. What 
a novel approach to traffic management 
—no traffic jams in the parking lot. 


A full schedule of forums were once 
again on tap. They ranged in subject 
from FCC and legal topics to the usual 


forwarding, our internal mail system 
works quite nicely. 


See the box below for the node nearest 
you. When you connect to one of these 
nodes, “H” will get you a list of the most 
frequently used commands. Give ita try! 


With the release PacketCluster 4-3, 
things have really 
become reliable, 
and as a result, 


N6IXX 


much less demand- K6LLK 
ing on the 
SYSOPS. AES) 


W60AT 


Along with the KN6J 


improved software, 
we have received 
assistance from 
WA8DED. Ron 
Raikes has given us 
invaluable advice 
on what parameter 
settings are best 
suited to a network 
like ours. 


WB2CHO 


KI3V 
KD6AZ 
K6PBT-6 
W6LEH 
K6XJ 
WAGIET 


Walnut Creek 
Mountain View 
Rio Linda 
Redwood City 
Santa Cruz Mountains 
Santa Rosa 
Reno 

Tracy 
Stockton 
Modesto 
Clovis/Fresno 
Santa Maria 


“How to” seminars. AMSAT is gaining 
in popularity and it’s evident at Dayton. 


Saturday evening gave us a good ex- 
cuse to get away from northern Dayton 
and into the downtown convention center 
for the banquet and awards ceremony. 
There isn’t a better filet mignon that side 
of the Mississippi, and Ronnie Milsap 
was an entertaining speaker. 


When it’s all over and the booths have 
been torn down, the Hara Arena looks 
like an abandoned warehouse and the 
parking lot looks like the aftermath of a 
major tornado. But the Bombay Bicycle 
Club is open for a great dinner and a 
chance to relax. And if you’re stuck in 
Dayton for an additional day due to air- 
line restrictions, check out the Air Force 
Museum. It was the second time for us 
and even more enlightening with the ad- 
dition of their SR-71 (a retired spy plane 
that was parked in the middle of an ad- 
joining field). By the time you board 
your own plane to head home, your feet 
have declared themselves AWOL and 
your wallet is empty. Oh well—you 
have a year to recover! 

EOT 


These parameters are quite different 
from those found as defaults on TNC’s. 


WA8DED’s assistance and advice 
will be the subject of my next 


article. EOT 


145.770 
144.950 
144.950 
145.770 
146.580 
144.950 
144.950 
No VHF 
No VHF 
146.580 
144.950 
144.950 
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Emergency BBS for Tactical EOC-to-EOC Packet 


Traffic 


W. E. Moerner WN6I 


fis traffic between Emergen- 
cy Operations Centers (EOCs) 
often consists of short messages request- 
ing or providing status updates. As is 
usual, the use of packet radio can provide 
a modicum of security for such messages 
while also freeing up voice channels for 
other uses. For the purposes of this docu- 
ment, “EOC” should be regarded in the 
broad sense to signify major emergency 
operations locations, such as city EOCs, 
County Communications, Red Cross 
chapter headquarters, etc. This docu- 
ment describes a packet radio scheme for 
handling EOC-EOC tactical traffic in a 
widespread emergency that was dis- 
cussed during the Santa Clara County EC 
Council meeting on March 1, 1990. 


..it appears easiest to rely 
on a system that uses BBS 


technology and terminology. 


Se LTTE EES TS SY RE PRES EEO 
Although there are many ways in 
which packet radio could handle such 
message traffic (e.g., TCP/IP, BBS, key- 
board to keyboard), the majority of hams 
who have used packet radio are already 
well-versed in BBS usage. In order to 
have an easily accessible system that re- 
quires minimal training, can be used on 
a variety of computers, and tolerates 
many different packet stations, it appears 
easiest to rely on a system that uses BBS 
technology and terminology. A further 
advantage of a BBS is its ability to auto- 
matically store the traffic that was 
passed; killed messages do not actually 
disappear until a sysop command is given 
and can remain as a log of the event. 


The following assumption is made 
within Santa Clara County: each EOC 
will have a packet operator who knows 
how to connect to a BBS using AX.25 
protocol. The EOC or operator may have 
more capabilities and training (com- 
puter, knowledge of TCP/IP, etc.), but in 
an emergency, it makes the most sense to 
configure a system that requires only 
minimal skill and equipment. The 
simpler the system is, the more likely it 
is that it will be functional in an area- 
wide disaster. 
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One method of passing traffic be- 
tween EOCs might be to ask each EOC 
to connect directly to each of the other 
EOCs. This type of multi-connected, 
keyboard to keyboard network is imprac- 
tical to use in an emergency as a good 
path must be established between all 
pairs of locations. A much more realistic 
network is a star-shaped topology with a 
central BBS at a moderately high loca- 
tion to which all of the EOCs connect to 
send and receive traffic. In this con- 
figuration, each EOC need only provide 
a good path to the central BBS. 

PRE ee REN ag NRE AO SSO BS RMS aE WL ES DEA 

It is essential for the central 
emergency-oriented BBS to 
be separate from the normal 
BBS network. 


SSSA aE ESE EE EST ES OS 

It is essential for the central emergen- 
cy-oriented BBS to be separate from the 
normal BBS network. In a disaster, the 
stations using the emergency BBS must 
not be distracted by such things as "for 
sale” messages, general QSTs, and health 
and welfare traffic; these services are 
already handled well by the standard 
BBS network. 


A further requirement for the central 
emergency-oriented BBS is that it have 
multiple connect capabilities. Many 
EOCs need to pass traffic and must be 
able to connect at the same time rather 
than wait for the BBS to be free. The 
exact maximium number of active sta- 
tions on one frequency is limited by the 
1200 baud data rate of many current 
TNCs which implies about 4-6 stations 
on the same frequency. In order to hand- 
le 10 or more EOCs, multiple ports are 
also required. 


BBS callsign: WN6I-6 
Frequency: 
BBS program: 
Location: 


A final requirement for the central 
emergency BBS is automatic emergency 
power as power failure is likely during a 
widespread event. 


In the event that the coverage area is 
extensive or the number of EOCs is large 
enough to overload one computer, two or 
more emergency BBSes can be estab- 
lished which are linked by a backbone 
frequency in a small network. This 
scheme also provides back up 
capabilities in case one of the BBSes 
malfunctions. For example, in Santa 
Clara County, it may be useful to estab- 
lish a northern BBS and a southern BBS 
and to connect the two in a backbone. 


Our emergency BBS system is cur- 
rently composed of the following ele- 
ments: 


1. A multi-connect BBS at a 
central high level location in the 
county on emergency power. We 
have selected at this time the “BB” 
mailbox program by AA4RE be- 
cause it provides many connections 
on each of several ports. 


2. Packet stations at the various 
EOCs (including County Comm 
and other major locations such as 
Red Cross Chapters). 


During the emergency, the EOC sta- 
tions all connect to the BBS as required. 
The EOC stations can send messages to 
other EOCs, receive messages addressed 
to them, and then disconnect until they 
again need to send or receive traffic. We 
have defined a particular convention for 
setting callsigns and beacon text which 
makes traffic passing very convenient. 
The convention we use for sending and 
receiving messages is described at the 
end of this document. In essence, the 
stations set the AX.25 callsign (i.e., 


223.56 MHz and 144.91 MHz 
AA4GRE BB version 2.8 
IBM Almaden Research Center in 


San Jose at 1000 feet, with 
automatic emergency power and 
automatic restart 
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MYCALL) to the tactical ID, and the 
amateur station callsign is placed in the 
beacon text with a 10 minute beacon 
interval. In the near future the BB 
software will be enhanced to implement 
tactical ID’s in a more elegant manner; in 
this sense, the scheme described here is 
only a temporary stopgap measure. 


In the case that an EOC has a personal 
mailbox running in their TNC, the central 
BBS can be configured to automatically 
forward mail to this TNC. This means 
that the EOC need only connect to the 
central BBS when sending traffic; it is 


not necessary to connect to see if there is 
any pending traffic to be received. 


To test these concepts and to have a 
system on the air immediately in case the 
next earthquake occurs tomorrow, we 
have set up such an emergency BBS sys- 
tem for testing and immediate use if a 
disaster occurs. This system uses donated 
personal equipment and a site provided 
by the IBM Amateur Radio Club. 


We encourage EOC packet operators 
to connect to this BBS to determine if a 
good path exists. This will help us to 
determine if a second BBS is required 


and where it should be located. If re- 
quired, you may choose to use one of the 
digipeaters on 223.56 such as NT6V-4 
and N6IIU-4, although it would be best 
to locate the emergency BBS(s) where no 
digipeating is required. Several 
digipeaters are also available on 144.91 
MHz. 


This system will evolve with time as 
we gain experience; however, it is most 
important to have at least a starting sys- 
tem on the air. As usual, comments and 
suggestions are welcome. 


EOT| 


Emergency BBS Operation Rules 


WNoI, N6KL, NOMWD 


5. For the title of the message, use something descrip- 


he following information provides the abbrevia- 
tions to be used when sending messages from 
EOC to EOC via the BB Emergency BBS. 


1. Each station has a short-tactical ID as shown in the 
list below. Set MYCALL to your tactical ID. For ex- 
ample, San Jose EOC would set MYCALL to SJEOC. 


2. At the same time, to satisfy FCC regulations for 
Station identification, the beacon should be set to a 10 
minute interval, and put your amateur radio callsign in the 
message text. For example: 


MYCALL SJEOC 
BEACON every 60 
BTEXT San Jose EOC station, AA6HX 


NOTE: After the event is over, be sure to remember to 
restore MYCALL to your FCC-issued callsign AND be 
sure to type “BEACON EVERY 0” to turn off beacon 
generation! 


3. Even though the emergency BBS allows many 
stations to be connected at the same time, stay connected 
only as long as necessary to get your mail and/or to send 
mail. 


4. With these assumptions, you can send mail from 
one EOC to another by simply using the tactical callsign. 
For example: 


s lgeoc (to send a message to Los Gatos) 


CAMEOC 
CUPEOC 
CNTYCOM 


Campbell 
Cupertino 

County EOC 

(at County Comm) 
Gilroy 

Los Altos 

Los Altos Hills 


GILEOC 
LAEOC 
LAHEOC 
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Pacific Gas & Electric 


tive about the person to whom the message is addressed. 
For example: 


Joe Smith 
6. As always, within the message, use good amateur 
practice by specifying: 


To: Name and Position 
From: Name and Position 
Text 

(Date and time are automatic.) 


Msg for Mr* 


7. If you are SJEOC, see what messages have been 
sent to you by typing: 


1> sjeoc 


This will allow you to see what messages are “to” 
San Jose. Then read the message by typing: 


r # (# is the actual message number) 


Or, use the command “rm”, which means “read 
mine.” 


8. To see if a message you sent has been read, look at 
the message status field. A “Y” means the messge has 
been read by the recipient. You can delete messages sent 
to you or sent by you as required using “k #”. 


9. Here are the standard abbreviations to use: 


SCEOC 
SAEOC 
STAEOC 
LGRC 
SUNEOC 
SJIRC 
PARC 


Santa Clara 

Saratoga 

Stanford 

Los Gatos Red Cross 
Sunnyvale 

San Jose Red Cross 
Palo Alto Red Cross 


Los Gatos 
Milpitas 
Morgan Hill 
Mountain View 
Palo Alto 


San Jose 
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Building a “Real” Network 


Brian Lloyd, WB6RQN 
124 Churchill Avenue 
Palo Alto, CA 94301 
wb6rqn@k3mc 


brian@telebit.com 


OE item that I noticed upon get- 
ting on the air here in the South 
Bay area is that there simply is no real 
network that supports TCP/IP and the 
network that supports the other AX.25 
users (BBS and DX Packet Cluster) is 
tenuous at best. It is my feeling that, if 
properly architected, the TCP/IP net- 
work and the BBS network (for want of 
a better word) can actually come together 
to form a common network. 


Building the network backbone 


The current practice of using simplex 
frequencies shared by more that two net- 
work backbone “neighbors” is very poor. 
AX.25 does not deal well at all with 
trying to share a frequency. The key to 
an effective backbone is to create reliable 
point-to-point links. In addition, full- 
duplex links are very desirable because 
they more than double the throughput 
(the improvement in throughput can be 
ten times or more in some cases). The 
network nodes should communicate 
point-to-point using cross-band full- 
duplex, e.g., node A transmits to node B 
on 70 cm while node B transmits to node 
A on 1.25 M. The result is that there is 
no link turnaround and ACKs can get 
back to the sender while it is sending thus 
keeping the flow of information going at 
full speed. 


Full-duplex operation of the back- 
bone links also produces another benefit: 
few or no retries. This, along with more 
available bandwidth, results in fewer 
delays and reduced memory requirement 
in the node or conversely the ability of a 
node to handle more traffic. The beauty 
of full-duplex operation is that it can be 
accomplished with minimal change to 
existing facilities. 


The key to constructing full-duplex 
links involves having receivers and 
transmitters that can operate simul- 
taneously. Most of our existing voice- 
grade radios are inherently half-duplex 
and can only serve a half a link. The 
transmitters are the hardest to come by 
but our existing radios will serve as the 


required transmitters. Fortunately for us 
inexpensive outboard receivers that will 
cover a variety of frequencies and bands 
are readily available -- as VHF/UHF 
scanners. The major problem with scan- 
ner receivers is that their front-ends tend 
to be broad banded (by design) and they 
tend to have a somewhat high noise fig- 
ure. Both of these problems can be cured 
by a combination preamplifier and heli- 
cal resonator, such as the one sold by 
Hamtronics. This may not be needed at 
every link site so, as they say in the UK, 
just “suck it and see.” 


Full duplex operation will work with 
almost any type of node including 
TCP/IP gateways, NET/ROM nodes, and 
even TexNet nodes. The key is if the 
equipment can generate packets while it 
is receiving packets. If the TNC software 
does not provide an option to enable full 
duplex operation (FULLDUP ON) you 
can simply disconnect the carrier detect 
line from the modem to the comm chip. 
Now the node will transmit whenever it 
has data. As an additional mod you can 
setup the transmitter to remain key-down 
all the time eliminating all key-up delays 
(it might be prudent to add fans to the 
heat sinks). Most TNCs shut down the 
audio to the transmitter when they are not 
sending data. You will have to defeat 
this feature so that the transmitter 
generates HDLC Flag sequences when 
no data is being transmitted. The node 
should also generate an ID packet every 
10 minutes regardless since the transmit- 
ter is always on the air. 


Now what do we do with all this stuff 
when faster radios become available? 
We just drop the faster radios into the 
place of the slower radios and run them 
full duplex as well. The existing 
Heatherington (WA4DSY) 56 Kbps 
modems are designed to operate full 
duplex so they will work just fine in this 
environment. The proposed 250 Kbps 
Elmore/Rowett 33 cm radios are in- 
herently half-duplex but there is nothing 
to stop someone from only populating 
half the board, either the receiver or the 
transmitter, so that full-duplex becomes 
possible. 


Choosing the Networking 
Protocol 


The foregoing discussion of full- 
duplex does not preclude any networking 
protocol currently in-use or proposed for 
amateur digital communications. Some 
implementations, however, offer more 
expansibility and upgradability. I per- 
sonally would choose a proven, standard 
networking protocol such as IP over 
NET/ROM for backbone communica- 
tions. The routing protocols for IP are 
more mature and IP can handle asym- 
metrical routing (asymmetrical routing is 
where the path from A to B may be 
different from the path from B to A thus 
allowing one-way links to exist in some 
areas). Also IP offers us the ability to use 
commercial networking components and 
to interoperate with existing networks -- 
a significant plus in times of emergency 
when all resources must be used. 


But I suspect that many of you are 
now asking, “gee, that’s great for the 
IPers but what about the guy with just a 
dumb terminal and a TNC? How does he 
or she participate?” The AX.25 users 
and the BBSs are supported by terminal 
servers in their local area networks. The 
terminal servers function in a manner 
very similar to an existing NET/ROM 
node in that you connect to the terminal 
server and then command the terminal 
server to connect you to someplace else 
in the network. The terminal server can 
even be programmed to connect a user to 
a host or BBS automatically. This makes 
things very simple for the user -- a real 
plus in times of emergency because they 
do not need to know a map of the network 
to send and receive messages. 


Since the network backbone runs 
TCP/IP it is very easy to add multi- user 
UNIX systems to function as application 
servers. These application servers can be 
programmed to appear just like a stand- 
ard WORLI or WA7MBL BBS so that the 
users will feel right at home. On the 
other hand the BBS mode can provide a 
command that allows the user to have 
access to the entire capability of a UNIX 
system, a feature that no ordinary BBS 
can ever hope to offer. The power of the 


Continued on page 11 
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HF Packet of The Future 


Raymond Petit W7GHM 


n March of 1990, AXOX and 

W7GHM conducted a series of one- 
way tests of a new HF data communica- 
tion system design over the 1500 mile 
path between Boulder, Colorado and 
Oak Harbor, Washington. On 5 different 
days, and on the 80, 40, 30, and 15 meter 
bands, Ed sent text from Isaiah 55 to Ray 
at higher speeds than any other data mode 
was able to deliver in the same band 
conditions, and Ed’s “Cloverleaf” signal 
was sO compact that twenty of them 
could have been packed, without mutual 
interference into the same 2 kHz space 
now used by one packet channel. 


On 15 meters, Ray was printing data 
at 75 bits/sec free of errors. (The fastest 
HF packet transfer rate observed in a 
series of BBS file downloads under ideal 
band conditions was about 70 bits/sec.) 
On 30 and 40 Meters during a time when 
the packet link between AKOX and 
W7GHM was nothing but retries, Ray 
got 50 bits/second from the Clover link. 
The design limit of AMTOR is 33. On 80 
meters, when it was necessary to repeat 
single letters several times on CW to be 
understood, the Clover link delivered 15 
bits/second, free of errors. 


Clover Beats The Multipath 


During a series of tests just completed 
by Willard Shockey, N7JTQ and 
Raymond Petit, W7GHM, a one-way 
Clover link delivered throughput-per- 
bandwidth performance from about 50 to 
over 1000 times better than HF packet in 
the severe multipath environment of a 
nighttime 50-mile path on 80 meters. 


The first test began at 10 pm on April 
29. The Clover link transferred data at 
37 bits/second on a sustained basis 
without losing or garbling any data. Wil- 
lard and Ray were unable to establish a 
packet link because the TNC’s retried out 
making connect requests. 


The second test began at 9 pm on 
April 30. The Clover link delivered 75 
bits/second with one in ten of the data 
blocks lost. (The two-way Clover 
protocol will provide for retransmission 


of lost blocks without requiring 
retransmission of blocks already correct- 
ly received). Shortly after 10 pm an at- 
tempted file transfer on packet was 
aborted after a few minutes by a link 
failure. The average data rate was 0.7 
bit/sec. A second attempt produced a 
nearly identical result. The Clover one- 
way link then delivered 117 blocks of 
data at 50 bits/sec, losing only two 
blocks. 


On May 2 at 7 pm the third test was 
conducted. The conditions were much 
more stable, and a 2K file transfer on 
packet averaged about 31 bits/second. 
Afterwards the Clover link delivered 75 
bits/sec. At about 8 pm another packet 
file transfer averaged about 17 bits/sec 
and it was followed by a Clover data 
transfer at 50 bits/sec. 


The performance “figure of merit” 
was obtained by dividing the number of 
correctly-received bits per second by the 
spacing (in Hertz) required to guarantee 
that two signals of the same type do not 
cause mutual interference even if one is 
60 dB stronger than the other. For a 
Clover signal, this spacing is 100 Hz. 
Packet and AMTOR require at least 20 
times this space. 


Ultra-narrow Bandwidth 


For practical purposes a Clover signal 
is entirely contained in a channel only 
100 Hz wide. A Clover signal in the 
neighbor channel will not cause inter- 
ference even if it is 60 dB stronger than 
the signal to which the receiver is tuned. 
A network of 10 Clover links can be 
maintained without mutual interference 
ina 1 kHz band. Each channel is a “clear 
channel”: no collisions, no “splatter”, 
and no keyclicks come from the other 
users, even if they are much stronger. 


Adaptive Two-way Protocol 


A Clover link communicates data at 
the highest speed the RF propagation 
path permits. As the band conditions 
change the system adapts to them auto- 
matically. Under the best conditions it 
operates at above 100 correct data bits 
per second delivered to the user. Under 


the worst conditions, conditions in which 
even CW data rates approach zero, a 
Clover link can communicate a few bits 
per second. 


Corrects Errors 


The Clover design uses Reed- 
Solomon error-control coding to correct 
errors in transmission, rather than reject- 
ing a block of data on account of the 
errors. The coding is set such that it will 
recover blocks which have as many as 
10% of their data symbols lost. If too 
many errors occur, the receiving station 
obtains aretransmission from the sender. 
Itis never necessary to retransmit a block 
of data which has been received success- 
fully on account of errors in previous 
blocks. 


Easy Interface to Application 


The data link is completely 
transparent to the data user. No restric- 
tion exists on the alphabets or data se- 
quences. There are no illegal data codes. 
Input is accepted as a sequence of bytes 
and delivered to the output of the link in 
the same format. Programs using a 
Clover link are totally free to define their 
data in the ways best suited to their needs. 


Frequency and Time Stable 


The Clover modem requires and takes 
advantage of the extreme frequency 
precision and stability of its transceivers. 
It also requires accurate knowledge of 
time. The transceivers obtain both the 
frequency and time information automat- 
ically from observations of a primary 
frequency and time standard (WWYV, for 
example). A Clover channel can be 
centered 50 Hz from a band edge with 
confidence. 


A Gift to the Amateur Radio 
Community 


Two Clover transceivers are under 
construction. When the system has been 
verified by extensive additional on-the- 
air testing, the complete specification for 
this new mode will be released to the 


public domain. 
EOT 
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Pacsat Protocol Suite — An Overview 


Harold Price NK6K 
Jeff Ward GO/K8KA 


he authors have been struggling with the question “How 

can we make the best use of a bandwidth-limited low 
earth orbiting digital store-and-forward system with a 
worldwide, unstructured, heterogeneous user base?” since 
December, 1984. In answer, we have proposed the use of a 
broadcast protocol as the basic downlink method, and a “file 
server” rather than a BBS application. This document provides 
a brief overview of these conclusions, the companion specifica- 
tion documents provide the implementation details. 


A PACSAT, a generic term which encompasses both the 
University of Surrey’s UO-14 and the AMSAT microsats AO- 
16 and LO-19, is a bandwidth limited device. The number of 
up and downlinks is much less than the number of users, and 
the capacity of the link is much less than the offered load. We 
feel that this is the critical design driver, and the access methods 
must be optimized with this in mind. 


Broadcasting 


A spacecraft is inherently a broadcast device. It transmits 
from on high, and many users can hear it at the same time. 


To optimize the available downlink time, we are recom- 
mending the use of a broadcast protocol. This protocol adds 
information to each data packet to permit many stations to 
make simultaneous use of a single file download session. 
When one station in Maryland requests the current orbital 
element sets, there is no need for stations in Toronto and Miami 
to do the same, they should be able to make use of the infor- 
mation as it is downlinked to Maryland if they are all in view 
of the satellite at the same time. To make use of a broadcasted 
frame of data, each frame must be tagged with the file it belongs 
to and the position within that file that the data belongs in. 


There should also be enough information for a station to 
determine if it has all of the data belonging to a file, and if not, 
to request that just the missing parts of the file be retransmitted. 
The specification titled “PACSAT Broadcast Protocol” 
describes a method of providing this additional information. 


With a broadcast protocol, a groundstation can simply 
monitor the downlink and accumulate files of data. Since files 


hese are the current versions of the PACSAT 

protocols as of O8May90. An addition 
specification, the low level file transfer protocol, will 
be available shortly. 


DATASPEC.STP 
Definition of the definitions. Draft 5. 


BROADCST.STP 


The broadcast protocol. Draft 8. 


FHEAD.STP 
The standard file header. Draft 6. 


gathered in this way will have been unsolicited, the format of 
the contents may not be known to the user. For example, if one 
asked for a file of NASA format orbital elements, one can make 
a good guess that the resulting file contains NASA format 
orbital elements. However, if a “random” file is captured, its 
contents may not be understandable simply from inspection. 
Some additional information, such as a file name, data type, 
description, creation date, etc., may be required. Each broad- 
casted file, therefore, needs a header in a standard format with 
this information. The specification titled “PACSAT File 
Header Definition” describes a method of providing this infor- 
mation. 


We hope that the broadcast protocol will maximize the use 
of the downlink. It should reduce the number of requests for 
files of general interest. It should also reduce the uplink load, 
since a broadcasted file does not receive an ack for each frame 
or group of frames. In the best case, only one “ack” is sent for 
an entire file, and that would be the request to stop broadcasting 
It. 

File Server 


As a data transfer and storage device, a PACSAT can serve 
a multitude of purposes. In can store telemetry, digitized voice 
and video images, personal mail, forwarded mail, or anything 
else the can be stored in a computer file. Mail forwarding is a 
good example of an excellent use ofa PACSAT. AO-16’s 1200 
baud link could easily be used to transfer 240k bytes of uncom- 
pressed forwarded mail in each direction between California 
and England in 24 hours, with just one moming and evening 
pass over each location. UO-14’s 9600 baud link could move 
1.6 Mb of data in the same time. A PACSAT can store up to 
8Mb of data. This would make a powerful addition to the 
current HF relay network. 


The problem, however, is that the current amateur network 
is in a State of flux. New addressing schemes are proposed 
every few weeks, new routes and new ways of routing are 
proposed, tried, discarded or modified. This is good. Im- 
plementing the software on a spacecraft to follow these shifting 
designs is difficult, however. The testing required for the 
spacecraft is more rigorous, especially on the microsats, where 
the same computer is used for the BBS and to keep the batteries 
charged. Faulty forwarding code could crash the computer, 
which could cause damage to the batteries or reduce their life 
expectancy. 


The amount of program memory is limited on the spacecraft 
as well. To counter the effects of high energy particles above 
the earth’s atmosphere which cause memory bits to be changed, 
the PACSATSs use 12 bits to store 8 bits of program data. The 
extra bits are used to correct for single bit errors. To keep the 
cost down, and to reduce the power used (AO-16’s CPU uses 
about 500 milliwatts, on average), only 256k bytes of program 
space is available. 


We have a desire, then, to keep the spacecraft code simple 
and stable, while still allowing it to be a useful part of the 
changing amateur network. 


We propose that the spacecraft be primarily used as a file 
server, moving data files from one point to another. The 
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PACSAT would have no knowledge of the contents of the files, 
nor would it take an active role in the forwarding of mail 
messages. Groundbased software could, however, make the 
PACSAT system look like a familiar BBS to the user, and it 
could intelligently forward mail. 


A PACSAT will know how to receive and transmit a stand- 
ard file format. All files will have a standard header, the same 
one that is used by the broadcast protocol. It will also know 
how to select files for transmission based on the contents of the 
header. This feature can then be used by groundstation 
software to emulate any desired user interface. 


For example, assume that a user wanted to send a personal 
mail message to a friend. In the current terrestrial environment, 
he would connect to a BBS, which would lead him in a question 
and answer session something like this: 


Remote Computer User 

What do you want? Send message 

To whom? Fred 

Title? Club meeting 
Message? Meeting at 8 p.m. 
What do you want? Read new mail. 
Message #200.... 


Using the PACSAT system, exactly the same exchange 
would take place, except that the conversation is between the 
user and his local computer. The message is stored for later 
transmission toa PACSAT. The read new mail request is also 
stored. The next time the PACSAT comes overhead, the 
computer does the following: 


¢ Builds a file with a standard PACSAT header. The 
header says that the file contains a mail message, from 
you, to Fred. 


* The file is compressed, and sent to PACSAT. 


* The local computer then sends a message to PACSAT 
that says: “send the next file who’s header meets the 
following criteria: it’s a mail message type, the destina- 
tion is me, and the file number is bigger than x.” 
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Continued from page 8 


“x” is the number of the last file received on the ground, and 
is kept by the local computer. After the pass, the local com- 
puter can now print any new mail received. To the user, it 
looked pretty much the same. 


What about file forwarding? A forwarding gateway would 
need to know what type of mail it could forward. Let’s assume 
that the routing scheme of the week is based on a hierarchical 
string containing states, like nk6k.ca.usa, and this gateway 
handles mail to CA, NV, and OR. The gateway would send a 
message to PACSAT containing the following request: 


“Send the next file who’s header meets the following 
critera: it’s a forwarded message, and the destination 
string contains ‘?.ca.?’ or *?.nv.?’ or “?.or.?’, and the 
download count is 0.” 


The file would be received, decompressed, and imported 
into the standard BBS program after the pass. 


In this way, the ground program can be as simple or as 
complex as required, the PACSAT only needs to know how to 
select a file for transmission based on the contents of field in 
the standard file header. 


Summary 


These two ideas, broadcasting and file server, are certainly 
different from the current common usage of packet radio on the 
amateur bands. We feel that this is the best approach for the 
special case of a PACSAT, however, and that with suitable 
groundstation software, these concepts can be integrated into 
the mainstream. A prototype of the broadcast file transfer 
method has already been implemented by one of us, Jeff Ward, 
and is currently being tested on UO-14. There is still much 
implementation work to be done. 


Comments on this paper and on the referenced specifica- 
tions are solicited. Address comments to: 


Telemail: HPRICE or VOSAT 
Compuserve: 71635,1174 
Packet: NK6K @ WB6YMH.#SOCAL.CA.USA.NA 


EOT 


Kbps, and higher, as the RF hardware 
becomes available. The full-duplex 
point-to-point links should support a 
very large number of users with very few 


UNIX system will make new applica- 
tions easier and faster to construct. 


Actually “doing it” 


In the south bay area several of us are 
going to begin construction of the 
aforementioned network. Currently we 
are planning on between three and five 
nodes interconnected using full-duplex 
links on 6M, 1.25 M, 70 cm, and perhaps 
33 cm and 23 cm. User access to the 
network will be on 2M as it is now. Each 
area will have its own 2M frequency 


There will be at least two battery- 
backed UNIX systems to provide ser- 
vices to the users. The UNIX systems 
will also provide the name server func- 
tion so that end users will not need to 


know the addresses of all the other users. 


in the network. This network will also 
have a gateway to the standard BBS net- 
work and may have a gateway to the 
Internet if we can solve the problem of 
preventing non-ham access to the 
amateur packet network. 


As time goes by the RF links will be 
upgraded from 1200 bps to 9.6 Kbps, 56 


retries. The nature of the network will 
prevent the congestive collapse that is 
typical of current amateur packet radio 
networks. 


I hope that this article spurs your in- 
terest. We are looking for other hams 
who are interested in assisting us and 
participating in the new network. If you 
have questions or comments please ad- 
dress them to wb6rqn@k3mc (BBS), to 
wb6rqn@a.wb6rqn.ampr.org 


(SMTP/TCP/IP), or to 
brian@telebit.com (Inter- 
net/uucp). EOT 
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Walking Mobile Packet Radio Station Around 
The Earth 


Fred Moore, KG6HQ 

Walking Rainbow Earthpilgrim 
784 Rosewood Drive 

Palo Alto, CA 94303 


The computer would be used to write and designs to optimize them, keep a diary 
publish articles about my designs, foraneventual book about the walk, play 
prepare graphics and technical drawings, with cellular automata programs for en- 
simulate and model the physics of these joyment and insights into how natural 


tel. 415-327-1104 


[Editor's note: Fred is one of 
those free spirits that actually 
practices what he preaches; he 
represents, I think, a little part of 
us all. And he is not some far-out 
weirdo: Fred founded the 
Homebrew Computer Club! See 
the book “Hackers” by Steven 
Levy. We hope you enjoy Fred’ s 
short article.] 


have been walking south 
from Vancouver since 
August 31, 1989, and crossed the 
Golden Gate into San Francisco 
on Earth Day. This walk, which 
I call the “Walking Rainbow,” is 
a long term non-commercial 
project to promote respect for the 
earth by living simply in har- 
mony with nature. Less is best. 


Combining high tech and low 
tech, I have designed and built 
two lightweight “tension-struc- 
ture” carts to carry my camping 
equipment and supplies. (I don’t 
need two carts, but bring them 
both so that other walkers who 
join will have use of a cart. Each 
cart can carry 300 Ibs or more.) I 
am testing out a portable single- 
pot wood-burning cook stove of 
my design which is fuel efficient 
because the air is pre-heated 
before entering the combustion 
chamber. I also have plans for 
building a portable solar oven, a 
portable yurt, power assist motor 
for going up hills, corn grinding 
brake for slowing downhill, and 
Other appropriate tools for 
nomadic living. 


While in the S.F. Bay Area for 
a couple of weeks, I plan to equip 
the carts with 12 volt photo-vol- 
taic modules to power a portable 
computer and packet radio gear. 


Walking for a green earth 
Pushing colorful carts 

15 miles a day on average 

With rainbow banners 

And Earth Flag flying. 

Heading south to meet people— 
Listening, learning, respecting all. 
Discovering in our diversity 

A balance—harmony with nature. 


On a search for how to live simply 
Within a nomadic community. 
Combining high-tech and low-tech 
In the design of appropriate tools 
For living lightly on the earth: 
Carts, bikes, portable yurts, 
Single-pot cook stoves, solar ovens, 
Photo-voltaic modules for powering 
A portable computer and 

Satellite communictaion equipment. 


Can we find a sustainable economy 
That values the web of life, 

That sees ourselves as part of nature, 
That no longer treats the earth 

As a commodity? 


Walking is a meditiation— 
A time for reflecting 

On what is important. 
Walking puts us in touch 
With our body, 

With the Feminine, 

With our being. 

Walking reminds us 

To stay humble 

And to continue to give thanks 
To the earth. 


—Fred Moore 


systems might work, maintain 
and address list of contacts, 
and be the terminal for packet 
radio communications via the 
Microsats while I am walking 
in foreign countries. So Iam 
looking for a portable com- 
puter workstation that can be 
used in the field, such as an 
AGILIS System. I welcome 
help in locating sponsors for 
this project. Advice and tech- 
nical assistance are also 
needed. 


[Editor’s note: I know that 
Fred is Most Interested in 
finding a way to get an inex- 
pensive Macintosh Portable 
to take with him; any helpers 
out there?] 


The walk route will take 
me down the coast to Los An- 
geles, east through Arizona, 
New Mexico, Texas, and 
south from there (Mexico, 
Central America, South 
America, etc.). Ill be check- 
ing in to the packet frequen- 
cies on 2 meters and 70 cm 
along the way and would be 
delighted to meet hams inter- 
ested in this venture. Perhaps 
a few amateurs would be will- 
ing to act as base stations and 
gateways to various computer 
nets for the reports I’ll be 
sending back when I’m south 
of the border. It is going to 
take some advance work to get 
permission to operate packet 
in other countries and I need to 
begin that process now. Any 
suggestions of contacts in 
Mexico or Central America 
who could assist in this 
process would be greatly ap- 
preciated. Thank you. 


EOT| 
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9600 Baud Packet Meeting Minutes 


Minutes of the 9600 baud packet meeting held 6 July 90. 


Ron Bardarson, NoVUW 


Attendees 


AA6IW, KG6HQ, KK6KR, N6TQS, 
N6VUW, N6XQF, N6YVB, WA6VIY, 
WB6QZL. 


Interested Others: K3MC, KA6FUB, 
N60IM, N6QMY, WB6GFJ, 
WD6CMU. 


A short preamble on the advantages of 
9600 baud packet, with a quick list of 7 
possible FSK systems was followed by a 
short discussion on the need to generate 
more interest in 9600 baud. A general 
discussion followed, with these results: 


Modulation Techniques 


Three possible 9600 baud implemen- 
tations were discussed: PSK, FAX, and 
FSK. 


PSK is interesting because of possible 
satellite compatibility, but since 
hardware availability was unknown it 
was not further considered. 


FAX is interesting as itruns ina 3 kHz 
bandwidth, experimental hardware ex- 
ists (AA6IW) but there are concerns 
about every connect requiring training 
and possible long turn around time. FAX 
costs are not less than FSK costs and 
further development work is required 
before it can be ’plug-and-play’. 


FSK is the oldest and best established 
technique, with numerous backbone sys- 
tems already in place around the country. 
FSK is at the plug-and-play’ level (get- 
ting to the varactor and discriminator is 
not that difficult, especially in older 
radios or Hamtronics units). FSK 
hardware in the form of G3RUH 
modems already exists at several QTHs 
in South Bay (with N6TQS and N6bVUW 
placing orders as a result of the gather- 
ing), TAPR K9NG (probably 
packetRADIO) modems are compatible 
as they use the same scrambler algo- 
rithm. W2DUC/Hamtronics modems 


need a retro-fit of 
scramblers/descramblers to be com- 
patible. 


WB6QZL had a Pac-Comm G3RUH 
modem tied in with a TNC-2 clone which 
was examined with a lot of interest. 


A majority of the attending hams 
would employ the FSK 17-bit scrambler 
9600 baud systems initiated by KONG in 
1985 (4th Networking Conference) 
available from TAPR or the compatible 
G3RUH modems available from 
G3RUH or Pac-Comm. 


TAPR packetRADIOs are at least a 
year away from general availability, no 
one present was a beta site. 


Bandplan 


The NCXPN band plan’s 9600 baud 
frequency is currently listed as 145.71, 
but QZL commented that this frequency 
has been shifted several times. Since 
9600 baud systems are likely to be crys- 
taled, changing frequencies is not trivial, 
cheap, or fast. In reading the NCPA 
DOWNLINK from Spring 90, I find that 
changing the band plan has occurred and 
the latest is that DXPSN (spotting net- 
work) may move to 145.71 MHz with 
N6VV assigned to task of communicat- 
ing with all concerned parties (like US!). 


QZL is crystaled for 145.73, and it 
may turn out that a possible 9600 baud 
BBS also is already on 5.73. Since there 
are 16 packet allocations on two meters 
but only one of them is for 9600 baud (a 
situation that will change), I suggest that 
we start on the frequency that most of the 
crystaled equipment exists on, 145.73 
MHz and convince NCPA to change 
once more. 1200 baud users obviously 
have the flexibility to work their 15 chan- 
nel allocations. 


To obtain access to 5.73 we can either 
use the historical method or get official 
action from NCPA/NCXPN (i.e. 


AA4RE, K6RAU & N6VV) if they are 
an FCC recognized frequency coor- 
dinator. 


Other bands were considered, but two 
meters prevailed due to ease of access. 


Unfortunately, the notice for a July 
8th General Meeting of NCPA was dis- 
tributed too late for my attendance. 
[Editor’s note: there was no NCPA 
general meeting on July 8th.] 


BBS 


There are TWO potential offers of a 
BBS available to support 9600 baud 
packet. Details are currently under dis- 
cussion, further blow-by-blow accounts 
may appear....but I’d probably just report 
the end result. 


A BBS is a KEY requirement for a 
successful 9600 baud packet group. 
Multiple BBSs will help to improve the 
available frequency allocation situation. 


Coordinator 


I was selected to be the information 
exchanger, contact point, and part-time 
radio surgeon. 


No formal organization is needed yet 
for this small group, all communication 
between members will occur via the ex- 
isting 1200 baud network (for which we 
owe thanks). Future growth will require 
a more formal organization. 


As an REF staff engineer, I have access 
to equipment to support varactor and dis- 
criminator mods. The ’group’ will act to 
assist others to get 9600 baud up and 
running throughout SF Bay at the user 
level, a chance for NorCal to be first 
again in the packet community. 


Next meeting 


To Be Announced at a Later Date, 
watch for it. 


73 and no retries 
N6VUW@NG6IIU.4NOCAL.CA.USA 
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Northern California Packet Association 


NCPA (NCXPN) H&W Traffic Committee 


Minutes for Meeting, June 9th, 1991 


Walter Borlase, N6LDL 


he meeting convened at the Los 
Gatos - Monte Sereno Red Cross 
Building at 1:00pm. 


Attendees 


Steve, KA6ETB, NTS Packet 

Dave, N6JQJ, SEC Santa Clara V. 

Roy, AA4RE, Programmer 

Eleanor, KA6VEU Marin County OES 

Bob, WA6VOI, Marin County OES 

Roger, WB6HZO, Marin County OES 

Steve, KB6HOH, Marin Co. RACES 

Weo, WNO6I, Santa Clara (ARES Data) 

Sharon, NSMWD, ADEC Santa Clara 

George, WA6YYM, DEC Santa Clara 
Co. 

Russ, NW6U, Santa Cruz RACES 

Frank, N6FW, West Ops HQ ARC 

Gene, N6ANE 

David, AA6RM, EC San Francisco 

Jim, KA6IVF, EC Central CCC 

Jim, N6PWX, Contra Costa Co. 

George, KI6YK, SYSOP & EC CCC 

John, W6VOM, NTS-ALCO RACES 

Doc, W6ZRJ, HVP ARRL 

Bob, KB6FEC, ARES, AEC SV 

Scott, KB6U00, ADEC Santa Clara 

Gordon, KC6JAE, NALCO / West CC 
ARES 

Jim, K6APW, NTS - NALCO 

Walter, N6LDL, Sr.AEC Los Gatos 
/SYSOP 


Objectives 


1. Define the expectations of 
ARES/RACES, and their user agencies, 
of the NCPA AX.25 Bulletin Board Sys- 
tem in processing Health and Welfare 
traffic in an emergency. 


2. Submit recommendations to the 
NCPA (NCXPN) board. 


NCXPN Packet System 


Walter, N6LDL, opened the meeting 
with a brief presentation on the NCXPN 
BBS system. Emphasis was on forward- 
ing capability and the current lack of a 
defined priority standard. All mail is, for 
the most part, treated equally. A handout 
was made available for all attendees. 


EOC-EOC BBS System 


Weo, WN6I, discussed the EOC-EOC 
BBS system planned for Santa Clara 
based on the multi-connect REBBS 
software. While the emphasis is ex- 
pected to be on tactical traffic, Weo did 
indicate that there was some expectation 
that limited H& W Traffic could be ex- 
pected as well. How traffic would be 
handled beyond the EOC-EOC BBS sys- 
tem was not yet an issue. While hooks 
into the NCPA system are possible (it 
uses standard REBBS protocols) there 
are none currently planned. 


ARES Database 


Weo then went on to the ARES 
Database system. This multi-connect 
on- line packet system allows the user to 
define a limited database file (five fields 
available) to keep track of volunteers, 
victims, etc. It’s use in emergencies is yet 
to be established as there is some concern 
about having names transmitted over an 
open channel that could be monitored by 
others. It is for that reason that the Red 
Cross, for example, is not likely to use the 
database for keeping track of shelter vic- 
tims. Thus it is not likely that having an 
automated request program against the 
database would be useful unless an agen- 
cy wanted to use it to keep track of volun- 
teers, for example. The ARES Database 
has some limited BBS capability, but its 
primary application is as a packet 
database. 


NTS System 


Doc, W6ZRJ and Steve, KA6ETB 
confirmed that packet is not a 
‘sanctioned’ ARRL NTS medium for 
moving the mail. While a fair amount of 
traffic is moved on packet, there is al- 
ways ongoing concern that packet is an 
open loop system. That is, the unat- 
tended automated forwarding capability 
is seen as a mixed blessing. The mail can 
move through the system without any 
human intervention, but it can just as 
easily get stuck on a board without an 
NTS operator, and is thus subject to the 
interest’ of the sysop or traffic designee. 
Other dilemmas are crashed hard disks, 
ill kept systems or forwarding stations, 
etc. In the ’normal’ NTS system there is 
supposed to be a live human to take the 


handoff between voice, CW, 
RTTY/AMTOR nets to reduce (you can 
never eliminate) the chance for lost or 
unhandled mail. Until such time as there 
is a responsible NTS Packet Manager in 
every BBS system the decision of ARRL 
Management is likely to remain un- 
changed. 


A significant majority felt 
that incoming traffic should 
be ‘rejected back’ to the in- 


coming gateways... 


SSNS SEES OE Ie ES CE Te SOE IS, 

One point brought up in the meeting 
was the use of ARL codes versus plain 
text in NTS traffic. While general con- 
sensus was not requested, it was under- 
stood that using these codes for 
international traffic was causing traffic to 
go undelivered in some of the Americas, 
Australia, etc. Walter, N6LDL did point 
Out that several messages from sysops 
around the world asked that plain lan- 
guage be used throughout. In fact, in 
some cases the ARRL codes were caus- 
ing political problems for foreign sysops 
as their bureaucrats can, and have, taken 
the codes to be secret messages to third 
parties. 


RECOMMENDED ACTION: Use 
only plain text in packet NTS messages. 


Red Cross 


Speaking on behalf of the Red Cross 
Frank, N6FW, said that they were not 
prepared to support incoming H& W traf- 
fic for at least 72 hours (except requests 
via MARS). While the ARC feels the 
focus should be on outgoing H&W traf- 
fic, they are not prepared to set up a 
formal structure with amateur radio until 
we Can guarantee delivery within 3-days, 
as is currently the case for the U.S. Postal 
Service. Frank did say that outgoing traf- 
fic could be voluntarily handled by the 
hams by setting up tables in shelters and 
taking messages from victims for trans- 
mittal to loved ones. The use of ham 
radio for reporting the status of victims 
in shelters, however, was not likely to be 
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What Was the Question? 


An alternative opinion on the report of the H&W Committee 


Don Simon NI6A 


\ ,' J ell, 1 kinda expected the results 
that occurred in the H&W 


Meeting for many reasons, not that I 
think that it is functional nor that it will 
help ham radio or victims any. 


The first reason it failed is that one 
almost never gets anywhere asking ECs 
what they want to do with H&W traffic. 
They all have much more serious busi- 
ness to take care of and most are short 
handed. Most ECs also never check intro 
NTS nets (a few very rare exceptions) 
and most are a bit intimidated by NTS 
format and feel thus either defensive/ag- 
gressive or at least shy in an NTS struc- 
ture. As you know, an EC has to try to 
find operators to man operations 24 
hours/day during disasters and top coor- 
dinate with many agencies, and to train 
their manpower. To take pride in what 
they are supposed to do almost requires 
a fulltime job. This I have learned being 
assistant EC to 3 different ECs and work- 
ing closely with many ECs throughout 
Northern Calif but mostly Contra Costa 
and Alameda Counties. 


Of course there have been a few ex- 
ceptions. The old NAPA EC, N6XN, 
used to be an NTS op and we actually 
handled over 300 welfare messages 
during the NAPA fire in 1983 through a 
combined effort of NAPA ARES and 
NTS. WB6UGG, Barry, the CDF coor- 
dinator and former DEC for South SCV 
Section, was also very supportive, but 
these are exceptions. Thus, if you ask the 
questuon from ECs and from agencies, 
they almost always agree that they are 
over-worked already and do not want to 
deal with it, it’s just an extra burden. 
During a disaster they are mostly burned 
out and like chickens with their heads cut 
off. This is not to depreciate their fine 
efforts in the field of emergency com- 
munications (versus welfare). Of course 
this doesn’t mean that it can’t be done. 


Now, if the task of the H& W Commit- 
tee was defined as how can we provide 
the H&W service for loved ones via 
amateur radio and, in particular, amateur 
packet radio, how could we improve on 
what we did (and a lot of what we did was 
done very well at least in SFD and East 
Bay and I am sure there also), then I think 


we could have gotten somewhere. In 
other words, if we ask the wrong ques- 
tion: “What do ECs want?”, we would 
get the answer that we got. ECs are not 
NTS or Welfare oriented. There is a 
small statement in EC, SEC, and DEC 
job descriptions about Welfare and NTS 
interface, but it is purposely vague. (A 
point of contention with the ARRL and 
myself for many years.) 
a ea a aS RE Oe 
..t0 ask for an automatic 
moratorium, whether or not 
we can handle welfare traffic, 


is more than self defeating... 


So, what could we do to get the job 
done despite the ECs, despite ARES, 
despite, ARRL, and, yes, despite many in 
NTS leadership itself. If we had asked 
this question, I think that many software, 
hardware, and organizational answers, or 
at least possibilities, would have oc- 
curred. If we look at the 1989 Earthquake 
Welfare effort it wasn’t so bad consider- 
ing there was no grand plan existing. So 
we SHOULD ask: What could we do to 
improve that? How could planning help? 
Can better software and procedures be 
established nationwide to get the job 
done? I, of course, think the answer is: 
Yes. If packet proved that it could move 
thousands of messages even with no 
plans, just think what could have been 
done with some intelligent forethought! 


The tragedy (in my opinion) is that 
NTS exists on a daily basis to provide 
message services and message handling 
training, but almost every time during a 
disaster when the chips are down and the 
commercial systems fail, NTS fails to 
mobilize despite the fact that the physical 
RF links are there. But normal NTS nets 
are limited to not more than 200 mes- 
sages per area per day. It breaks down 
during a large fair, special event or dis- 
aster. Packet however lends itself excep- 
tionally well to the task. High bulk traffic 
could be moved nationally in and out of 
the dsiaster area as a COMMUNICA- 
TIONS SYSTEM FOR THE PUBLIC. 
Wow! What a good human use of 
amateur radio! What a great service to 
victims and their families when long dis- 
atnce lines are down for days and some- 


times for over a week! What great public 
relations for amateur radio! Who could 
be against it? 


Ignorance is against it. Over-worked 
ECs who think that NTS is in competition 
with ARES, or NTS ops who think that 
ARES is in competition with NTS, or 
NTS guys who may think that packet is 
in competition with NTS, etc. These 
guys, fortunately, are not in the majority, 
but they are established in various circles 
which were well represented at the H& W 
committee meeting. 


The actual proposal of the question, in 
other words, was: What does ARES 
want? What does Red Cross want? 
What does NTS want? These questions 
would bring predictable and unoppor- 
tune results. If these were the questions 
the NCPA board wanted to answer, then 
they got predictable answers. As a long- 
time member of all 3 organizations, it 
was not surprising to me. 


So to ask for an automatic 
moratorium, whether or not we can hand- 
le welfare traffic, is more than self 
defeating—it emasculates the system, 
makes it dysfunction and condemns it to 
irrelevance. It kills morale and wants us 
to take up golf or chess...hi. 


Maybe experience will change some 
guys minds, maybe GENIE or Compu- 
Serve or other satellite-based com- 
munications systems will take over and 
leave amateur packet in the dust. 
Anyone is free to create a local delivery 
system. 99.9% of the inquiries will be for 
those who are actually unaffected but 
who have lost long distance commercial 
telephone service and can be reached 
through local exchanges. This number is 
from actual experience. To me, it is a 
valuable service if we can assure people 
that their close friends or relatives are 
safe in times of disaster when multiple 
casualties have occurred and long-dis- 
tance telephone service is unoperative. 


Yes, we could discourage inquiries. 
Certainly all inquirers should know that 
delivery is not guaranteed. The point is 
that people will try to communicate via 
any way possible to find out about their 
loved ones during a disaster. Certainly 
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ever sanctioned as every effort is made to 
protect the identity of the victims, and 
our bands are not secure. H&W Traffic 
at the request of the victims, however, is 
not so limited. 


ARES/RACES 


Dave, N6JQJ, Section Emergency 
Co-Ordinator for Santa Clara, made it 
clear that ARES/RACES resources were 
generally stretched to the limit in an ex- 
tensive incident like the last earthquake. 
Accordingly he is taking the stand that he 
can support H&W traffic ONLY TO 
THE EXTENT REQUESTED BY THE 
SERVED AGENCIES. In short, unless 
the agency(ies) initiate it ARES/RACES 
isn’t going to handle it (at least until the 
manpower is available to support 
‘general’ NTS type H&W traffic). 
David, AA6RM, EC for San Francisco 
echoed the same sentiments. 


The chair then asked the group to 
focus on issues and recommendations. 
The following summarizes the various 
statements offered. While some are 
repetitive to those expressed above, they 
are repeated here as they were re-em- 
phasized at this time. 


1. Packet should be used for repetitive 
and/or complex technically long mes- 
sages. It should also be considered for 
traffic that would normally have been 
sent digitally (modem) but the normal 
path is not available (e.g. phone lines are 
down). 


2. The Red Cross looks at packet in a 
transparent way. How we handle the 
traffic is left to us. They would use it for 
H&W traffic if we could give them 
strong assurances that any and all traffic 
accepted for delivery would be delivered 
within 3 days, as currently ’guaranteed’ 
by the postal service. 


3. ARES (Santa Clara) indicated that 
they are committed to support H& W traf- 
fic FOR SERVED AGENCIES ONLY 
(at least to start). So incoming NTS traf- 
fic does pose a problem, at least short 
term. Further, if the bbs system is tied up 
with incoming traffic that cannot be ef- 
fectively handled (because the same 
people are being committed to voice 


nets), then it won’t be of much use for 
other emergency traffic. 


4. Roy, AA4RE, rose to point 3. by 
suggesting the programmers could write 
code that would allow the sysop to put 
the BBS into an emergency mode that 
would have one or more of the following 
attributes: 


a. Restrict access to those 
authorized by SYSOP. 


b. Reject incoming bulletins, 
NTS and personal traffic unless it 
carried an agreed code (like “Z”) 
that only could be authorized by a 
sysop, or designee. This is seen 
mostly as a gateway function as the 
bbs would have to send back a 
reject message based on the fact the 
bbs is in the emergency mode with 
restricted access. Limited access 
and restricting messages to those 
coded with, say, SZ would com- 
plete local control. 


c. Advise all SYSOPS that 
BBS’s in the emergency mode will 
reject all traffic save that carrying 
the agreed code. Further, only Red 
Cross, MARS H&W, or other 
authorized agency’ originated traf- 
fic should be allowed to carry the 
emergency designator. John Doe’s 
emergency traffic will have to wait 
until the bbs system in the affected 
area has been returned to normal 
use. In short, the SYSOP controls 
traffic TO the affected area too. 


d. As noted in a. & b., outgoing 
bulletins (about the emergency), 
and NTS traffic would be 
processed, subject to the restricted 
access limitation. Personal mail 
would be blocked as would general 
bulletins. One option to restricted 
access might be to allow open con- 
nects but entry restricted to NTS 
traffic, and bulletins only by 
‘authorized’ connects, etc. 


There was general agreement in sup- 
port of the emergency mode capability, 
and restricted access to the BBS. Not 
clarified was whether limited access was 
total, or as described in (d.) above. 


Roy also indicated that code could be 
included to allow the SEC to initiate the 
emergency mode, but Dave, N6JQJ, felt 
that should be a sysop function. While 
he is prepared to ask the sysop to switch 
to the emergency mode, he felt that local 
conditions might well dictate the ap- 
propriate response too. 


5. A significant majority felt that in- 
coming traffic should be ’rejected back’ 
to the incoming gateways, except as 
authorized under Roy’s suggestion, until 
the bbs can be returned to ’normal use’. 
However, outgoing H&W traffic should 
be encouraged. 


6. Does NCPA need an Emergency 
Coordinator??? The point was raised, 
but no consensus reached. (Chair: 
Maybe each SYSOP needs to consider 
their role as a potential emergency bbs in 
their city and/or county.) 


7. Several attendees suggested ARL 
codes be dropped for emergency (and 
normal) NTS type packet traffic. (See 
NTS recommendation above.) 


All attendees are invited to comment 
on the minutes which will be submitted 
to the board in early July. As the board 
requested recommendations primarily of 
ARES/RACES representatives, it is clear 
that we should recommend the hold on 
traffic, the initiating of an emergency 
mode capability, and limited’ access to 
the bbs system. This must further be 
rationalized with another committee 
formed to explore the use of the BBS 
system for handling tactical traffic in an 
emergency. 


Corrections to the minutes must be 
submitted by June 30th to be assured they 
are incorporated or appended. Com- 
ments by others, and submitted by June 
30th, will be passed on as an Appendix. 
Such comments (minutes or general) 
should be sent as a bulletin SB H&W @ 
ALLCAN. 


IF YOU DISAGREE WITH THE 
RECOMMENDATIONS CONTACT 
YOUR SEC/DEC/EC WITH YOUR 
ARGUMENTS AND SEEK RECON- 
SIDERATION THERE. 


Respectfully submitted, 
Walter, N6LDL @ N6LDL 


EOT 
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SAREX, 144.95, DXPSN, BBSs, and Keyboarding 


Mike Chepponis K3MC 


he upcoming SAREX mission 

(recently posponed -due to 
hydrogen leak) will be using the frequen- 
cy 145.550 as a packet downlink from 
space, with three uplinks: 


144.950 (Primary frequency) 
144.910 
144.970 


The primary frequency is -600 kHz 
from the shuttle downlink freq, so we can 
use the -600 kHz offset on our radios. 
(Actually, if one has a separate rx and tx, 
full duplex can be used, but that is a 
different matter.) 


NCPA has 144.950 allocated for 
DXPSN. I have been in contact with 
Tom Wood, N6IXX (the DXPSN 
Liaison to NCPA) about this, and have 
received from Jay O’Brien, W6GO, his 
thoughts on the subject. 


144.95 is the home for six Packet- 
Cluster nodes, as well as one backup 


node. In addition, five NetRom nodes 
support the PacketCluster system on that 
frequency. Getting these nodes and the 
hundreds of users of this system to QRX 
for the 10-minute passes during the 10- 
day STS-35 mission seems like an im- 
possible task! But Tom and Jay have 
agreed that if NCPA can find a temporary 
frequency for the DXPSN operation on 
144.95 during the SAREX mission, then 
they would work to temporarily move all 
of the PacketCluster nodes and as- 
sociated NetRom nodes, even though this 
may require new crystals for some of the 
rigs. The NCPA Frequency Coordinator 
is working on finding such a frequency, 
and we applaud the spirit of cooperation 
that Tom and Jay exemplify as part of 
DXPSN and NCPA! 


But, even if we accomplish this tem- 
porary QSY, all is not peaches and 
cream. If Tony England, WA4SIR (the 
ham aboard the STS-35 mission) finds 
too much QRM on 144.95, he will listen 
on the other two frequencies. Since 
144.910 is a keyboard channel, we 


hereby request that all keyboard users be 
aware that the 144.91 frequency may be 
used during SAREX passes, and to try to 
QRT during those passes. 


144.97 is a BBS channel; again, we 
request that the BBSs on that channel 
QRT during the time of the shuttle pass, 
or risk QRMing the shuttle. 


The good part is that the shuttle will 
be in a low-inclination orbit. This means 
that, for the duration of the 10-day mis- 
sion, there may be perhaps three passes, 
and these passes will all be in the eve- 
ning, and will be at most 10 minutes long 
and be spaced at approximately 90- 
minute intervals. Therefore, disruption 
to normal packet operations should be 
minimal. 

Jay is working with W3XO and the 
ARRL to ensure that future SAREX mis- 
sions do not use frequencies that are in 
such widespread terrestrial use. 


So, thanks everybody for helping us 
all cut through this Gordian knot! 


73 de Mike K3MC 
EOT 


What Was the Question? 


Continued from page 15 


some of the inquiries are not always from 
close friends or relatives, but that doesn’t 
mean that the others are somehow less 
valuable. WE will not be able to prevent 
people from trying. If it is stopped on 
packet, they will try on SSB or GENIE or 
CompuServe or... My point all the time 
has been that amateur radio is a national 
communications service as defined by 
the FCC and that it may be able to play a 
functional role in this public service (as 
it often claims to do). 


The solutions here remain fairly much 
unaltered. The problem is basically one 
of communication, education, and or- 
ganization. It will require a lot of work. 
AAS DPE BEE SS OS Ot TRE ES 


..maybe GENIE or Compu- 
Serve or other satellite-based 
communications systems will 
take over and leave amateur 


packet in the dust. 
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Regarding the Red Cross, they have 
been looking for a way out for years. 
Basically, they are over-loaded with 
more basic inadequacies and similarly do 
not want to “bother” with the service. I 
think that some sort of national disaster 
message service may eventually emerge, 
independent of Red Cross, perhaps a 
merger of GENIE and packet, by public- 
minded computer buffs who understand 
databases and data communications and 
are dedicated to getting the job done 
regardless of the methods. WNO6I is 


working on a H&W version of the ARES 
DATA that will act as a server for 
AAGRE BBS. I think that in the future, 
there will be a much better solution using 
computers than what has ever been pos- 
sible in the past using Red Cross TWIX 
systems or CW. The fact that there is no 
nationally dedicated amateur radio or- 
ganization in existence today that is task- 
ing itself with this project is disturbing, 
yes, but at the same time maybe that this 
will be some basis of a new and more 
relevant national amateur functional and 
human-orientated organization. 


73, Don 
EOT 


Imagine that Cray Computer decides to make a 
personal computer. It has a 150 MHz processor, 200 
megabytes of RAM, 1500 megabytes of disk storage, a 
screen resolution of 4096 x 4096 pixels, relies entirely on 


voice recognition for input, fits in your shirt pocket and 
costs $300. What’s the first question that the computer 
community asks? 


“Is it PC-compatible?” 
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Northern California Packet Association 


NCPA Board Meeting Minutes 


Minutes of NCPA Board Meeting 
May 6, 1990 


The Board of Directors meeting of the Northern 
California Packet Society (NCPA) convened at 1000 PST 
on May 6, 1990. Present at the meeting were the follow- 
ing individuals: 

WA8DZP WD6CMU WB9LOZ K3MC 

KA6ETB N6RAL N6QMY 


All board members except WA6ERB WA6JCW were 
in attendance. The board members are: 


WD6CMU WA8DZP WB9LOZ WA6JCW 
N6RAL N6QMY KA6ETB WAGERB 


Board Actions 


Old Business 


1. WA8DZP reported that there are a total of 170 
members as of the board meeting. 


2. WD6CMU reported that the current balance is 
$841.85. We have received a letter from Bank of America 
requesting our taxpayer ID number. 


3. No response has yet been received to our letter 
to the DXPSN asking them to send a representative to 
the board meetings. WA8DZP will send another letter via 
registered mail to see if they respond. 


4. K3MC attended the recent NARCC meeting as 
NCPA’s representative. AA4RE continutes to serve as 
NCPA Frequency Coordinator. He has sent a letter to 
NARCC concerning new 220 channels and asking for 
clarification on 900 MHz packet allocations. 


New Business 


1. N6RAL will invite KBETKL, the NCXPN Director 
to attend future NCPA board meetings. 


2. N6RAL was voted in as NCPA President. He 
previously was acting president. WD6CMU will remain 
as NCPA Secretary. N6RAL will contact WA6ERB to find 
out if he still intends to serve as a board member as he 
has missed the last two board meetings. 


3. WA8DZP contacted the Pacificon 90 committee 
as NCPA Liason and volunteered speakers and a booth 
for this years convention. He is to find out if WBSLOZ’s 
plan of doing paid packet seminars at the Pacificon site 


will be allowed. DZP will report back to the board on the 
results on the upcoming Pacificon planning meeting. 


4. K3MC reported on the status of the NCPA 
newsletter. The second issue was hot off the press and 
was distributed at the board meeting. It went into the mail 
the general members on May 2nd. The board decided 
that the newsletter could print material from our sister 
organizations such as the NCXPN. The board also ad- 
vised that any future articles which discuss the modifica- 
tion of radio equipment should include a suitable 
disclaimer. It was decided that enough money was avail- 
able to produce at least one more newsletter. It is hoped 
that the new members which are raised from new mem- 
berships will expand the coffers enough to publish future 
issues as planned. The deadline for articles for the 
Summer 90 issue is May 15th. 


5. The NCPA Pledge by WEMEO was referred to the 
NCXPN for comment. 


6. K3MC reported on the NARCC meeting. There 
were no packet-related issues raised at the meeting. 
NARCC is not coordinating below 912 or 918 MHz due to 
the automatic vehicle locating primary allocation which is 
going into service in our area soon. This action matches 
that of the SoCal coordinating body. 


Action Items 


1. The next board meeting will be on July 8th at 1000 
at a location to be announced. 


2. N6QMY will contact an attorney for advice on how 
to handle the taxpayer !D problem with Bank of America. 


3. N6RAL will obtain a copy of AA4REs letter to 
NARCC and send a copy to the secretary. 


4. N6RAL will contact WA6ERB to see if he wishes 
to remain on the board. 


5. WA8DZP will find out if the Pacificon will approve 
WBSLOZ’s plan to hold paid packet seminars at 
Pacificon. He will also act as NCPA Liason to the 
Pacificon 90 planning committee. 


6. K3MCwill investigate obtaining a bulk or 2nd class 
mailing permit for the newsletter. 


7. N6RAL will refer the WEMEO NCPA Pledge to the 
NCXPN for comment. 


EOT 


A Mexican newspaper reports that bored Royal Air Force 
pilots stationed on the Falkland Islands have devised 
what they consider a marvelous new game. Noting that 
the local penguins are fascinated by airplanes, the pilots 
search out a beach where the birds are gathered and fly 
slowly along it at the water’s edge. Perhaps ten thousand 
penguins turn their heads in unison, watching the planes 
go by, and when the pilots turn around and fly back, the 
birds turn their heads in the opposite direction, like 
spectators at a slow-motion tennis match. Then, the 
paper reports, “The pilots fly out to sea and directly to the 
penguin colony and overfly it. Heads go up, up, up, and 
ten thousand penguins fall over gently onto their backs”. 


—Audobon Society Magazine 


Page 18 


NCPA Directors 


Bob Bobrick, WA6ERB 
WAG6ERB @ KA6FUB 


Eric Williams, WO6CMU 
WD6CMU @ WD6CMU 


Bob Sanders, WA6JCW 
WA6JCW @ KD6XZ 


Chris Marley, N6RAL 
N6RAL @ N6IIU 


Michael Bothe, KBGOWT 
KB6OWT @ KB6OWT 


Steve Harding, KA6ETB 
KA6ETB @ N6LDL 


Patrick Mulrooney, NSGQMY 
N6QMY @ N6QMY 


Dewayne Hendricks, WA8DZP 
WA8DZP @ K3MC 


Larry Kenny, WB9LOZ 
WB9LOZ @ W6PW 


NCPA Officers 


President: 
Chris Marley, NGRAL 
N6RAL @ NG6IIU 


Vice-President: 
Eric Williams, WO6CMU 
WD6CMU @ WD6CMU 


Secretary: 
Dewayne Hendricks, WA8DZP 
WA8DZP @ K3MC 


Treasurer: 
Eric Williams, WO6CMU 
WD6CMU @ WD6CMU 


Newsletter Editor: 
Mike Chepponis, K3MC 
K3MC @ K3MC 


Frequency Coordinator: 
Roy Engehausen, AA4RE 
AA4RE @ AA4RE 
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Where toFind a BBS 


KJ6FY-1 
WB6JJI 
KA6LRR 
KI6YK 
WD6CMU 
N6EEG 
W6FGC-2 
KB6GOZ 
N6LDL 
WBE6EMIF 
KIGWE 
KD6XZ-1 
AA4RE-1 
KB6DUI 
WWE6L 
N6MPW 
N60A 
W6PW-3 
WA6RDH 
KI6EH 
Né6IIU-1 
KE6LW-1 
KG6XX-1 
W6CUS-1 
N6ECP 
KB6IRS 
N6IYA-2 
K3MC 
WA6NWE-1 
K6RAU-1 
WA6YHU-1 
KB5IC 
KA6JLT-2 
WO6Y 
KA6FUB 
WB60DZ-1 
KB6OWT-1 
N6QMY-1 
N6REB-2 


mean. 


Benicia 

Tres Pinos 
Hayward 
Danville 
Richmond 
Berkeley 
Twain Harte 
Petaluma 
Los Gatos 
Magalia 
Pleasant Hill 
Sacramento 
Gilroy 
Boulder Creek 
Piedmont 
Ben Lomond 
Lemoore 
San Francisco 
Dixon 

Santa Cruz 
Palo Alto 
Yuba City 
Carmichael 
Richmond 
Redding 
Soquel 
Felton 
Fremont 
North Highlands 
Merced 
Livermore 
San Jose 
Menlo Park 
Fairfield 
Martinez 
Lake Isabella 
Sunnyvale 
Fremont 
Modesto 


Steve Harding KA6ETB 
n a recent bulletin, VK4BBS presented some valid 

| Peres of the ARL numbered radiograms that NTS 
operators here in the United States use. It seems that those 
people who handle our formal message traffic outside of 
our borders have no idea what those funny ARL numbers 


144.93 
144.93 
144.93 
144.93 
144.97 
144.97 
144.97 
144.97 
144.97 
144.97 
144.97 
144.97, 441.50 
144.99 
144.99 
144.99 
144.99 
144.99 
144.99 
145.01 
145.07 
145.07 
145.07 
145.07, 441.50 
145.09 
145.09 
145.09 
145.09 
145.09 
145.09, 441.50 
145.09 
145.09 
145.73 
145.73 
145.77 
145.79 
145.79 
145.79 
145.79 
145.79 


The Band Plan 


144MHz 
144.91 keyboard-to-keyboard 
144.93 LAN! 
144.95 DX Spotting Network 
144.97 LAN 
144.99 LAN 
145.01 keyboard-to-keyboard 
145.03 keyboard-to-keyboard 
145.05 keyboard-to-keyboard 
145.07 LAN 
145.09 LAN 
145.71 9600 baud TAPR compatible 
145.73 LAN 
145.75 TCP/IP 
145.77. DX Spotting Network* 
145.79 LAN 
146.58 DX Spotting Network 
220 MHz 
223.42 node uplink (SBAY) 
223.52 node uplink (NBAY) 
223.54 node uplink (EBAY) 
223.00 keyboard-to-keyboard 
223.58 node uplink ("Other") 
223.60 node uplink (SACVAL) 
430 MHz 
100KHz-wide channels 
433.05 TCP/IP 
433.15 NET/ROM backbone 
433.25 DXPSN backbone 
20KHz-wide channels 
443.31 backbone 
443.33 backbone 
433.35 backbone 
433.37 backbone 
433.39 backbone 
433.41 LAN interlink 
433.43 digital experimental 
433.45 digital experimental & backbone 
433.47 NET/ROM interlink, keyboard 
433.49 TCP/IP 
441.50 all 


' 444.93 is used by TCP/IP in the Sacramento area. 
2 WO6Y remains on 145.77 as DXPSN/BBS liason. 


Sending International NTS Messages 


So, when sending formal traffic to a country with which 
we have a third party agreement, it is advisable to include 
a definition with the message, or, better yet, spell it out in 
plain English. It’ll increase the chances of the message 
being delivered on the other end. 


Secondly, always include a telephone number for the 
addressee. Many stations, particularly in Australia, refuse 
to handle any traffic without it. 
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What is NCPA? 


NCPA, the Northern California Packet Association, is an organization formed to 
foster the Digital Communications modes of Amateur Radio. So far, we have 
| defined our goals as: 


Mi Education 
MH Coordination 


«= Education means making information available about various Digital modes, and 
: this newsletter is but one part of that education process. 


neleteletetetobetatetatetetetdtetetetetatetetetetetetetetatatatatstetetete! 
SR 


Coordination activities include frequency coordination (NCPA is recognized by 
NARCC as the official packet radio frequency coordinator) as well as coordinating 
people and their various uses of packet radio, be they DX Cluster, BBS, TCP/IP, 
keyboard-to-keyboard, NET/ROM, Traffic/NTS, Emergency uses of packet, or even 
experimenting with new frontiers of various digital modes. 


We in NCPA believe that the next revolution in Ham Radio will come about in Digi- 
tal Communications Technology, and in the beneficial coordination among all 
users of ham Digital Communications Technologies. 


We invite you to join NCPA! Become part of the most dynamic group of packet 
folks in Northern California! 


he PP OOF RS SORELLE DR I MRE OT se OPROEIRIT TF PTO 
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NCPA Downlink 


Northern California Packet Association 
6680B Alhambra Ave. Suite 111 
Martinez, CA 94553 


First Class Mail 


